I have restructured the plugin a bit
You can now register love2d as a custom command and add a shortuct for it if you want to

local config = require "core.config"
local run = require "plugins.run"
local command = require "core.command"
local keymap = require "core.keymap"

config.run.love2d = "love ."
command.add(nil, {
  ["run:love2d"] = run.lang "love2d",
})

keymap.add {
  ["shift+f5"] = "run:love2d",
}

Have you seen the console plugin? I get the impression it may already solve the issue your plugin is trying to solve

Yes, I have used it, but I couldn't get it to work with infinite loops in my scripts, it didn't allow me to get user input, etc., so I've decided to use the native terminal and made this little plugin

I do see a niche usage for this idea. Sometimes I do work on standalone scripts that I don't have a project hook for.
Plugins eval and exec work on selected text and are pretty obviously detectable to what they do.
Your proposal does seem like it could fit into console plugin.

lite would require sockets in C-portion of code to enable a host of similar usages like this one where communication between a running application and lite is required.
Bare minimum FIFO file-socket support would give lite even greater extendibility. Something like this would also be nice to have: SDL2 based TCP socket bridge.

May I suggest naming this plugin something like runinterminal, to be more descriptive, if it should be accepted as independent plugin?

@SwissalpS good idea, I have renamed the plugin name to runinterminal as you suggested

This is hard-coding the gnome terminal on non-windows systems. I suggest to use an env-variable and default to gnome-terminal if not set.

I looked into it, although I am using a non-standard variable $TERMINAL, because $TERM often returns names that are not valid command names
And I have replaced gnome-terminal with xterm as it is installed on more machines and is generally more popular

I have also added a run.build method, which is same as run.lang except that it doesn't use the current doc's name and can be used when no file is open at all

@Qermon did you forget to switch branch? :D

Thankfully not, just resolving conflicts with rxi:master

Oh, sorry. I now see what happened :)

You can actually change it by putting something like config.run_cmd = 'some-terminal -some_arg "%s"' in your config module file, where %s will be replaced by the command assigned to a given language or build, for example editing hello.py will result in some-terminal -some_arg "python hello.py" being run.
The default command (and arguments) is there if a user doesn't set their own.

But if the default can already respect the user command in a non-breaking way, why should we force them?

Well, I've realized that $TERMINAL is not as viable an option as I initially thought, because many terminals use different arguments to accomplish the task, so it often breaks anyway.
I think it's better to just have the user set both their terminal and arguments or stick to xterm (and it's default args).